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An electronic data vault providing biometrically protected 

electronic signatures 

The invention relates to management of personal documents & 
5 data, identity information and any other information 
relevant to citizens. In this specification, the form 
"citizen" is intended to mean any person or user ( including 
consumers, employees etc.), and is not intended to be 
limited to any political definition of same. In particular 

10 the invention relates to the management v of documents 'knd 
data in a secure fashion using electronic (e-) signatures 
and in particular to a method and apparatus for utilising 
biometric techniques with such signatures. The term 
electronic signature is used throughout to indicate both 

15 symmetric key based electronic signatures and asymmetric 
(public key) digital signatures. 

At present, management of personal documents such as a 
passport or a driving licence is performed in hard copy. 
20 Performing transactions requiring such documents such as" 
taxing a motor vehicle typically involves a complex 
procedure with much manual handling of documents and use of 
the postal system. 

25 EP 0 917 119 describes a system for the safe, secure and 
properly authorized transfer of information while preserving 
individual privacy. It enables this by the provision of a 
first datastore including static identification, information 
for a user, a second datastore including moderately dynamic 

30 personal data about a user and a third datastore including 
dynamic demographic information about a user. By utilising 
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these multiple datastore it is possible to selectively 
access, organize and use personal data. 

US 6 105 131 discloses a secure server in a secure 
5 distributed information system that isolates interaction 
from terminals to specific personal vaults. A secure 
connection server is coupled to the system to enable 
authentication of a user and the data within the vault is 
protected against disclosure by encryption, against 
10 tampering by digital signatures and against un-trusted 
communications with unknown parties by digital certificates. 

Although these known systems provide a level of security for 
access to data, the security is not based on personalised 
15 security features and is therefore open to tampering by 
persons of unscrupulous nature. 

Electronic signatures are well known for the protection and 
authentication of electronic documents. They may be thought 
20 of as electronic code attached to (or associated with) a 
document which a) verifies the identity of the signer of the 
document and b) verifies that the document as signed by the 
signer has not been changed since the signing took place. 

25 One common example of electronic signatures, commonly known 
as a digital signature, relies on public-key cryptography 
and hash functions to provide this verification. It will be 
appreciated that within this specification that the term 
"electronic signature" refers to any signature process 

30 including symmetric and asymmetric signatures, whereas the 
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term ''digital signature" typically refers to an asymmetric 
signature. 

Figure 1 shows an example of a signing process that is 
5 utilised for the application of such electronic signatures. 
The document to be signed is sent to a one-way hash function 
(Step 1) that computes a small hash that is (practically) 
unique to the document (Step 2). This hash has ' 2 key 
properties; firstly the hash is unique to the contents of 

10 the document and any change in the contents will cause a 
completely different hash to be generated (good hash 
functions result in a completely different number being 
generated for even a single bit change within the document) ,. 
and secondly the hash is "practically" unique. In other 

15 words, the probability of two documents generating the same 
hash is extremely unlikely. This probability is a function 
of the size of the output hash and the "distribution'" of the 
algorithm across the bits in the hash. 

20 The hash itself is usually much smaller than the document 
itself. This is to allow public key encryption of it to be 
as fast as possible (given the processing power of some 
terminals and smart cards it is not currently practical to 
asymmetrically encrypt large documents (e.g. 1 MB of data) . 

25 For a given hash algorithm, the hash output is the same size 
regardless of the size of the original document. 

Next, the hash is sent to a signing function (Step 3) . This 
is effectively an asymmetric, encryption routine that uses 
30 the signer's private key to encrypt the hash. It should be 
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noted that for non-repudiation, there are certain 
requirements for the management of the private key. 

The document and the signature (which may be embedded in the 
5 document or linked to it in some fashion) are then sent to 
the recipient or stored (Step 4) . 

Figure 2 shows an example of how a signature on a document 
may then be verified. The signed document package comprising 

10 the document and the document signature is presented for 
verification (Step 20) . The hash values associated with both 
the document and the document signature are then computed. 
In the case of the document signature this computation uses 
the public key of the signer to decrypt the signature. This 

15 decryption produces the original document hash (Step 21) . 
The two computed hash values are then compared (Step 22) . If 
the hash values are found to be equivalent then the document 
is verified as having a valid signature (Step 23) If the 
values are not equivalent then the signature is found 

20 invalid. (Step 24) . 

Although these techniques are satisfactory in that they 
allow a level of security to be applied to documents that 
are transferred between two or more persons or institutions, 

25 the protected documents are still vulnerable to attack by 
unscrupulous persons. It will be appreciated from the 
explanation of how the signature is applied to a document 
(Figure 1) and how a document with a signature is then 
verified that all that is required for an unscrupulous 

30 person to impersonate the user's signature is to gain access 
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to the private key. Furthermore, the signature is only 
tested against the keys themselves, there is no recourse 
back to ascertain the actual identity of the user who 
created or owns the signature. Typically, the private key is 
5 electronically stored locally by the user on a personal 
computer/ laptop of the user or within a smart card 
belonging to that user. As such there is a possibility that 
a person of unscrupulous nature could gain access' to such a 
key by gaining access to the personal computer or smart card 
10 and thereby effectively impersonate the user. There, 
therefore, exists a need for a modified technique for use in 
the protection of electronic documents. 

Thus, the invention is directed towards providing improved 
15 convenience and security for management of personal 
documents and other items of data by citizens. It is a 
further object of the present invention to provide a method* 
and apparatus for the improved control of electronic 
signature systems . 

20 

Statements of Invention 



According to the invention, there is provided a citizen data 
vault and data processing system (eVault) comprising means 
for securely storing personal data and/or documents for 
citizens, and a citizen interface for allowing controlled 
access by citizens. 

In one embodiment, the system further comprises a service 
provider interface for allowing controlled access by service 
providers for (a) updating the data and documents and (b) 
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performing processes requiring access to the data and 
documents . 



In a further embodiment, the system comprises means for 
5 certifying data or documents. 

In one embodiment, the system comprises means for storing 
the data and documents in distributed locations and for 
prosecuting a single centralised view to citizens. 

10 

In another embodiment, the citizen interface comprises means 
for allowing access using a plurality of different types of 
devices including telephones and Web browsers, kiosks, ATMs, 
PDAs, mobile devices and the like. 

15 

In a further embodiment, the system comprises means for 
performing multi-modal biometric authentication . 

In one embodiment, the system further comprises a work flow 
20 processing sub-systems comprises means for executing 
processes in communication with service providers. 

In another embodiment, said sub-systems comprises means for 
enabling completion of service application forms online and 
25 for automatically populating parts of the forms using data 
retrieved from within the system. 

In another embodiment, the system comprises means for 
performing authentication or verification of citizens using 
30 biometric matching. 
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In another embodiment the system securely stores one or more 
citizen signing keys, and applies said keys to securely 
generate electronic signatures on the citizen's behalf. 

5 In one embodiment, the system comprises means for storing 
one or more cryptographic keys for citizens and for making 
them available for secure communication between the citizen 
and service providers or other third parties. By effecting a 
storage of cryptographic .keys and enabling access to these 
10 stored keys via an authentication of a user by means of 
verification of a user's biometric, the present invention 
provides an association between the biometric identity of 
the user and at least one cryptographic key for that user. 

15 In a further embodiment the present invention provides for 
the use of biometric technologies to provide a secure layer 
on top of electronic signature algorithms. 

The present invention enables the incorporation of a 
20 biometric identifier with a specific user's electronic 
signature by enabling the association of. that specific 
identifier with the signature at the time of creation of the 
signature. The invention may also allow for the association 
of a biometric identifier with a previously created 
25 signature. 

Typically, a biometric identifier is based on a biometric 
sample presented by a user. This sample may be used as the 
biometric identifier itself, or may be subjected to a 
30 processing wherein specific features of the actual sample 
are extracted and processed so as to form a biometric 
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template, which is linkable to the originating sample. 
Within the present specification the term biometric 
identifier is intended to cover both biometric samples and 
templates formed from such samples. 

5 

Accordingly the present invention provides a method of 
associating at least one cryptographic key with at least one 
biometric identifier of that user as detailed in the 
appended claims. The cryptographic key(s) are stored 
10 securely in a key trust, which can be thought of as a secure 
logical component of a user's e-vault data. The key trust 
may or may not be located physically separate from the main 
e-vault, as is possible within a distributed e-vault 
architecture . 

15 

The invention additionally provides a method of retrieving 
an electronic document as detailed in the appended claims. 

The method may additionally require the additional step of 
20 requiring a new user that is presenting a biometric to be 
associated with a prior registered user prior to any storage 
of personal identifiers for the new user. In effect, the 
prior existing user signs the biometric enrolment of the new 
user using the prior user's biometric to authenticate 
25 themselves. 

The present invention may optionally provide for an 
additional component, a biometric identifier, to be 
associated with the document. This, it will be appreciated, 
30 may be achieved by embedding a biometric identifier that has 
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undergone one or more transformations, into the document. 
Examples of such transformations include but are not limited 
to encryption using one or more keys and/or the application 
of a one-way function to the biometric identifier. 
5 Accordingly it will be appreciated that in this embodiment 
the present invention provides for the incorporation of one 
or mere biometric identifiers within an electronic signature 
5;c as :o effect an increase in security associated with that 
electronic si gna t ur e . 

10 

It will be appreciated that the present invention, in 
addition to associating the electronic signature with the 
biometric identifier, also enables the association of the 
biometric identifier with the owner of the biometric 

15 identifier. To this end, a record will be retained of the 
nature of proof of identity provided at the time of 
enrolment of the biometric identifier. This will typically 
be implemented in a similar manner to that currently known 
for the provision of public key infrastructure services 

20 wherein individuals are identified at the time that they 
are assigned asymmetric key pairs. 

It will be appreciated that the biometric identifier can be 
any one of a plurality of identifier types including but not 

25 limited to finger, iris, hand, face, voice and retina 

samples. Alternatively, as detailed above the biometric 
identifier may be a compact summary representation of the 
actual biometric sample, based on pertinent features* -of the 
particular sample. Such a summary is typically referred to 

30 as a biometric template. 
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These and other features of the present invention will be 
better understood with reference to the following drawings. 

Brief Description of the Drawings 

5 Figure 1 outlines the steps associated with a traditional 
form of electronic signature application. 

Figure 2 shows a known process for the verification of 
document signatures . 

Figure 3 is a schematic overview illustrating an eVault 
10 architecture according to the present invention. 

Figure 4 is a flow diagram illustrating a citizen eVault for 

storing of documents and information and provision of 

services using the documents, using Government services 

delivery as an example. 
15 Figure 5 is a diagram illustrating the eVault in more 

detail, illustrating a Government services delivery as an 

example. 

Figure 6 is .a high-level block diagram illustrating a 
Government services application processing systems. 
20 Figure 7 is a diagram illustrating logical database 
components of the eVault. 

Figure 8 is an eVault architecture diagram. 

Figure 9 shows components, access channels, and transaction 
flows that take place between a user, a service provider and 
25 an authentication engine. 

Figure 10 shows components and workflow within a 
biometrically-enabled authentication engine and associated 
authentication service . 

Figure 11 shows components, access channels, and transaction 
30 flows that take place between a user, an eVault, and an 
authentication engine, when the user authenticates to their 
personal eVault and requests a data processing transaction. 
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Figure 12 shows an enrolment process for associating a 
biometric identifier with a key or keys according to the 
present invention . 

Figure 13 is a modification to the enrolment process 
5 outlined in Figure 12, in accordance with another aspect of 
the present invention. 

Figure 14 outlines a generation process for the application 
of a biometrically protected electronic signature in 
accordance with the present invention. 
10 Figure 15 shows a process flow for a system where the. 
document repository is not fully integrated with the 
authentication engine in accordance with a modification to 
the present invention. 

Figure 16 shows a process flow for verification of . a 
15 signature in applications where the key trust does not want 
to send key material to the verifier in accordance with an 
embodiment of the present invention. 

De-bailed Description of -the Drawings 

20 

Figures 1 and 2 have been previously described with 
reference to the prior art so as to describe the traditional 
mode of application of a digital or electronic signature to 
a document or data. 

25 

The present invention, provides for the access to a user 
specific cryptographic key through a biometric associated 
with that user. By facilitating the association of a 
biometric with at least one cryptographic key the system 
30 enables the secure remote electronic storage of documents 
and data relating to a specific user. It also enables the 
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transfer from a local to a remote storage area of at least 
one cryptographic key associated with a user. This 
interaction between non-person specific security 
implementations and person specific enables the provision of 
5 secure networked infrastructures previously not possible. To 
understand the functionality of the type of network 
architecture that may be realised in an implementation of a 
syirter. of the present invention some of the typical 
ccnpor.ents will now be defined. These definitions are not 
10 intended to limit the present invention to the presence or 
otherwise of the specific components and are intended for 
illustrative and explanatory purposes only. 



Client 

15 A client is the client software resident on the 

biometric device and any associated computing devices 
such as Personal Computers, Personal Digital Assistants 
(PDAs), mobile phones etc. The client software is 
utilised by a user or citizen within the evault network 

20 environment. 



Authentication Engine 

An Authentication Engine (AE) is the entity responsible 
for capturing enrolments and asserting an individual's 
25 identity based on a presented biometric. The AE 

typically works in three modes. 

1. Verification - where both a unique claim 
and a biometric identifier are presented. 
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2. Identification - where only a biometric 
identifier is presented. 

3. Segregated Identification - where a 
partial claim (e.g. non unique claim such as 

5 date of birth or PIN) and a biometric 

identifier are presented. 



Biometric Reader 

A biometric reader is a biometric capture device. The 
10 term reader is intended to include devices suitable for 

reading various biometric modalities including finger, 
iris, voice, face etc . 

Key Trust 

15 A Key Trust is a highly secure component tasked with 

managing the private keys of the individual enrolees. 
The Key Trust carries out the signing of the documents 
on behalf of the signers - once their identity has been 
properly- asserted by a recognised AE . Typically, for 

20 security purposes, all signing operations are carried 

out in secure hardware, although it will be appreciated 
that this is not intended to limit the key trust 
application to such hardware configurations as 
alternatives may be apparent to' those skilled in the art 

25 ( for example, implementing the cryptographic routines in 

software) . 

Document 
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A document is an object that can be signed. Documents 
can include traditional electronic documents ' in a 
variety of formats (e.g. text, Adobe PDF etc.) or can 
include items such as images, binary files etc. 

Document Repository 

A document repository manages the documents that are 
being signed and optionally stores the resulting 
signatures . 

Certificate Authority 



The Certificate Authority (CA) is responsible for 
signing the public keys for all enrolees within the 
scheme. A CA is also usually required to issue and sign 
15 keys used by the various components (e.g. AE) which sign 

responses . 



It should be noted that a separate CA is not required in 
the scheme, and this is particularly applicable in 

20 certain applications of the method of the present 

invention where the issuance of a certificate may not be 
required. It is generally used if there are further 
applications, which want to carry out verification of 
the biometrically protected digital signatures. In many 

25 cases, if the system outlined here is the only system 

. required to validate the signatures, then the external 
CA may not be required - the authenticity of the keys 
being asserted by the Key Trust itself. 
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Enrolment Application 

An enrolment application is one that captures 'the 
enrolment information for a new enrolee. This may be a 
separate component related to the authentication engine 
5 or it may be a callable component integrated with a 

trusted partner application (for example a document 
management engine) . 

Utilising such architecture components it is possible for a 

10 user to be enrolled to use such a system according to the 
present invention, although it will be appreciated that such 
illustrated components are exemplary of the type of system 
architecture that may be utilised. The present invention 
provides a method of associating an electronic signature 

15 with a specific user. By storing a set having one or more 
personal identifiers associated with the user, the 
identifiers including at least one biometric .sample, and 
linking the set of personal identifiers with a key or keys 
generated for that user, it is possible to subsequently 

20 create a digital signature by providing at least one 
biometric sample. It will be appreciated that this set of 
personal identifiers typically includes information that 
conforms in large part to the data elements of x.500 
addressing, although as will be appreciated by those skilled 

25 in the art this is not intended to limit the application of 
the present invention to such addressing. 

In the case of x.500, such data includes: 

1 . Common Name 

2. Distinguished name 
30 3. Email 
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4. Organisation 

5. Organisational Unit 

6. Address etc. 

5 Within the present invention the components of a network 
architecture including a key trust, authentication engine 
and document repository form collectively what is called an 
eVault which provides functionality for storing and 
controlling access to citizen documents and information. . 

10 The eVault and associated processing systems provide for the 
citizen improved privacy and autonomy, convenience, 
security, personalisation, and compliance. The processes 
are citizen-centric and can include life event, identity 
confirmation, service/event tracking processes, and other 

15 personal processes. The eVault stores and manages basic and 
extended citizen, biometric identity, and service/event 
monitoring information. These processes can be implemented 
in conjunction with a Government services portal providing 
information about services and application forms. 

20 

Figure 3 shows a schematic of a network architecture that 
may be implemented using an eVault of the present invention. 
A user (100) and/or a service provider. (102) may connect 
over a network (104) to an electronic vault (eVault) (103) as 

25 provided for by the present invention. The eVault is adapted 
to provide an interface to a key trust (103a) which stores a 
user's cryptographic keys, a document and data repository 
(103b) wherein personal data or documents for that user may 
be stored and a biometric database (103c) which provides a 

30 storage location for one or more biometrics associated with 
that user. Interface to these repositories is provided upon 
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authentication of the user, which may be provided by an 
authentication application (103d), and authentication engine 
(103e) and an eSignature application (103f ) . The 
authentication application provides an interface to the 
5 engine, and may be provided with a policy management 
component. It will be appreciated that the authentication 
application could be incorporated within the engine such 
that all functionality was effected therein. Although all 
components are shown co-resident with one another, it will 
10 be appreciated by those skilled in the art that the eVault 
may be provided in a distributed architecture such that one 
or more components may be linkable to each other via a 
network or similar connection node. 

15 Figure 4 shows an overview of an implementation of an eVault 
service delivery model. As this diagram illustrates, the 
processes 1) of identifying and applying for serves and, 2) 
of Government processing of the services both involve 
accesses to the. eVault. The former processes also involve 

20 access to the Government portals. As illustrated in Fig. 5 
the eVault may be adapted to provide databases for: - 

Citizen core data/documents, 

Citizen private sector digital documents, and 

25 Citizen certified data from Government; digital 

documents i-uch as driving licence or passport for 
example 

The private sector documents can relate to matters such as 
30 car insurance, house insurance, health insurance, asset 
contracts and membership subscriptions. The Government 
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documents relate to mattes such as vehicle registration, 
VAT , and academic qualifications. 

Access control for the eVault is achieved by use of 
5 biometrics. A user's biometric is securely sent to an 
authentication engine component, where upon a successful 
biometric match, the user is granted access to their e- 
vault and all the services therein. The citizen does not 
need any tokens or codes and security is assured because of 
10 the irrefutable nature of biometric verification. In 
addition the system can support access to a limited subset 
of data via the use of tokens, pins & passwords. 

As shown in Fig. 6, in addition to the databases the eVault 
15 comprises an identity authentication application C, also 
termed the authentication engine, and a data management 
system D. C and D may interface with Government 

applications B, which in turn interface with Government 
delivery applications A. The combination of the eVault and 
20 the applications are together referred to as "eGov Process". 
There is both citizen and public service interfacing with 
the eGov Process (via applications B) . 

The eVault does not necessarily store citizen data in a 
25 single physical location. Referring to Fig. 7, the eVault 
has a highly scalable secure database platform, which can 
accommodate various categories of data, including multiple 
biometric identifiers (voice and fingerprint) , basic and 
extended citizen information in a form of ^virtual' 
30 database. Some components of data are stored outside of the 
basic database as ^extended' data. For example, as shown in 
Figure 7 the databases can be configured as internal, i.e. 
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localised with the 'eVault, or external, i.e. accessible via 
the eVault but not co-resident with the vault. This 
distribution is done in a manner providing controlled access 
so that it is the equivalent to being stored centrally. 
5 Portions of a user's logical eVault data may be held and 
maintained by an independent third party service provider. 
Typical data that would be stored locally would include the 
core biometric data relevant to the user such as the 
registered or recorded biometric identifiers and also the 
10 cryptographic keys associated with that user. The externally 
stored data is data or documents, which are personal to the 
user but not' of a highly critical nature such as digital 
documents related to passport, driving licence and the like. 

15 The eVault is highly secure, biometrically enabled, citizen 
centric, intelligent data vault. Various categories of data 
stored; personal information (name, address, PKI keys, other 
cryptographic keys, all forms of personal data etc.), 
electronic documents (passport, driving licence, car 

20 insurance certificate etc.) and a secure mailbox 
entitlements. Biometric .authentication of the citizen is 
required to securely access all data contained in the 
eVault. Depending on the access channel one or more 
different biometric types may be employed. For example, over 

25 a telephone line voice biometrics may be the most 
convenient, and the user's evault data will be tailored for 
that specific delivery channel. The eVault can supply 
personal information to other external systems based a 
positive biometric authentication. In addition the eVault 

30 will facilitate access to selected items of information via 
the use of tokens, pin & passwords. 
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The biometric technology provides a reliable, convenient and 
secure method to confirm personal identity using something 
that is uniquely part of every citizen. Current biometric 
solutions are classified as providing either identification 
5 or verification. Identification refers to one to many 
matching of biometric templates. Verification refers to one 
to one matching. The term authentication is used to refer 
to either biometric identification or verification. In a 
preferred embodiment, the eVault authenticates the citizen 
10 principally using voice and finger biometrics, although 
other biometric types may be found more suitable for 
differing applications . 

The eVault is a multi-modal biometric authentication 
15 platform, which is capable of scaling to a global level. 
Biometric identification and verification are provided for 
enrolment and identity verification respectively. The 
identification process (one to many matching of all 
biometric templates stored in the database) is designed so 
20 as to provide an automated response to the matching request. 
While one-to-many matching may be performed to prevent 
duplicate enrolments, it is not mandatory and may not be 
executed within systems that allow a single individual to 
enrol under multiple identities. 

25 

The eVault allows one to enrol on one biometric device, but 
to be authenticated on one of many biometric devices, 
capable of reading a biometric type that has been previously 
enrolled. This provides inter-operability of biometric 
30 devices. The system further provides for the enrolment of a 
subsequent user by a user who has already been authenticated 
by means of a biometric. 
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The eVault provides functionality to: 

• Perform a biometric authentication process prior to all 
5 requests to access (to view/add/update/delete/sign 

etc.) all the citizen data contained in the e Vault. 

• Provide secure Internet logon using finger scan or 
other biometric type access to all data stored in the 
'core general' and 'extended' database components. 

10 • Provide secure voice print logon access to selected 

components of the core general database. 

• Supply specific items of data securely from the eVault 
to external systems based on a positive authentication 
of the citizen subsequent to the data request from 

15 other external systems. 

For user access, the eVault: 



20 



• Enables the citizen to access the eVault content using 
a multiplicity of delivery channels such as Internet, 
TV, mobile protocols (e.g. WAP, iMode) , as well as more 
traditional standard personal computer (PC) access or 
telephone. PC access to the eVault will typically use 
the Internet platform and a finger scan device attached 
to the PC, although other interface systems may be 
found more practical. 

• Selects end user devices compatible with the 
proprietary biometric algorithms. 

• Ensures interoperability across a number of biometric 
30 hardware devices. 



25 



3DOCID: <WO_02103496A2_I > 



WO 02/103496 



PCT/IE02/00081 



-22- 

The following are additional features of the eVault: 

Authentication of the user/consumer to a very high 
level of probability. 

Protect the identity of the user/consumer to a high 
level . 

Ensuring confidentiality and integrity of the 
transaction by integrating biometric authentication 
together with PKI and digital certificate. 

Employ a database to monitor and track the 
biometrically enabled transaction together with PKI to 
ensure audibility and an audit trace that can only 
occur with the absolute consent and deliberate action 
by the end user /consumer , through the provision of 
their biometrics and other personal information. 

Providing a trading platform to exchange/trade /content 
to enable an electronic transaction such as renewal of 
motorcar tax. 

• Enabling a highly scalable architecture that could 
provide a global biometrically enabled e-vault. ; 

In one embodiment the eVault is built using the principles 
25 and standards of the Java 2 Enterprise Edition (J2EE) 
architecture. The specifications and models for operation 
for this architecture are published by Sun Microsystems. It 
is noted, and will be appreciated by those skilled in the 
art, that- it is possible to use many other known 
30 implementation languages and architectures to provide the 
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f unctionality and architecture of the present invention, and 
. J2EE is used as an example only. 

• The majority of digital documents and digital content 
5 data stored in the eVault and exchanged through the 

eVault are in an XML format. XML is a subset of the 
Standard Generalised Mark-up Language (SGML), which is 
an international standard (ISO 8879) . Control of the 
X:-!L standard rests with the World Wide Web Consortium 
10 (www . w3c . org) . 

rlach section of a typical eVault architecture is described 
below with reference to Figure 8. 

15 Citizen Channels (800) 

These are the channels through which the citizen using 
client software directly communicates with the eVault. For 
example, the citizen may use a telephone to communicate with 

20 the telephony channel and a web browser with additional 
plug-in to communicate with the web channel. The citizen 
channel is provided at the client side with a biometric 
reader so as to enable the capture of the biometric claim 
being presented by the citizen. The citizen can access the 

25 eVault from any PC with a web browser such as a home PC, 
Internet cafe, public library etc. From the web browser the 
citizen can view the information in the eVault, update it, 
if applicable, and even securely upload documents to or 
download documents from the eVault. Once the citizen has 

30 accessed the eVault, all communication is via a secure 
channel such as the Secure Sockets Layer (SSL) , which 
ensures the complete security of the information transfer 
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between the eVault and the citizen. In this format SSL 
provides confidentiality and integrity of the information 
passed between the citizen and the eVault. However it does 
not provide authentication of the citizen. It only provides 
5 authentication of the eVault. The citizen is authenticated 
to the eVault using biometric authentication. The citizen 
enters an identifier, unique within the eVault, and either a 
finger scan and/or a voiceprint or some other biometric 
identifier. The identifier and the biometric are combined 
10 into a biometric authentication request, which is be passed 
to the biometric subsystem which incorporates an 
Authentication Engine for authentication within the evault 
architecture. If the authentication request is verified, the 
citizen is granted access to the eVault. 

15 

Since access to the eVault is typically implemented using 
standard protocols such as HTTP or HTTPS, there are fewer 
restrictions on the use of this eVault by citizens operating 
within controlled environments such as corporate networks 
20 etc. 

If the citizen channel utilised is one such as a voice 
channel, the citizen can review and update information in 
the eVault using interactive voice response, .voice 

25 recognition and authentication. It is possible for the 
citizen to issue commands to accept documents into the 
eVault or to have certain documents or sections of documents 
within the eVault read back to the citizen. Since the 
citizen uses a dedicated telephone line during communication 

30 with the eVault, security of the information is ensured. The 
telephone channel provides the citizen with the most 
ubiquitous access channel possible to the eVault. 
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It is also possible in some implementations of an evault 
architecture to enable third parties access to documents or 
data specifically related to one or more users. Such third 
5 parties may typically be of the type "service providers" or 
"administrators" . The third party may directly request the 
data from the e Vault, or the eVault may automatically push 
the data to specific third parties, when it is updated 
within the eVault . 
10 Service Provider Systems (805) 

Service providers are those organisations both governmental 
and commercial, which provide services to citizens. Many of 
these service providers when dealing with a citizen will use 
15 the citizen's eVault to retrieve information about or store 
information for the citizen. Fig. 8 shows just two examples 
of service providers but it will be appreciated that many 
such organisations may be provided with access to an eVault. 

20 The service provider may make two requests of the eVault: to 
deposit documents or data within the eVault, or to access 
documents or data from the eVault about a citizen. 

Information Retrieval 

25 

Any request from a service provider to retrieve documents or 
data from the . eVault of a citizen will only be honoured by 
the eVault if authorised by the citizen. This can be done 
over a number of different channels but the principle is the 
30 same irrespective of the channel - the citizen must make a 
deliberate . and conscious act to facilitate the movement of 
information from the eVault. A policy management system 
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provides functionality to tailor, configure, and set 
defaults for the release of user data to service providers. 

From a technical perspective each retrieval request from a 
5 service provider is typically formulated as an XML document 
delivered over HTTP through the web channel of the eVault. 
These XML requests will contain an authorisation sub 
element. This sub element contains the information 
pertaining to the citizen authentication such as the citizen 

10 identifier, the biometric type (finger, voice etc.) and the 
biometric identifier. The XML request also contains a sub 
element for the digital signature of the service provider. 
In this way the requests with the digital signatures act as 
an audit log for non-repudiation. While a user biometric 

15 identifier may be collected and submitted through a service 
provider in this way, depending .on the access rights 
afforded to a specific service provider, its presence is not 
mandated. 

20 Information Depositing 

Any request from a service provider to store documents or 
data from the eVault of a citizen will only be honoured by 
the eVault if its source can be verified, and optionally if 
25 the data or document can be validated. The citizen must also 
agree to the document or data being stored in the eVault. 

Validation is done by comparing the document to be stored, 
to the template of the document and its associated rules. 
30 This ensures that the documents deposited by Service 
Providers are valid and correct. 
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Verification of the source ensures that the document has 
come from an appropriate Service Provider and only that 
Service Provider. Certain Service Providers will be 
authorised to produce certain specified documents and the 
5 eVault only accepts documents for a citizen from appropriate 
Service Providers. This ensures that the documents deposited 
by Service Providers are appropriate to that Service 
Provider i.e. a video store may not deposit a driver's 
licence in the eVault of a citizen. 

10 

Each deposit request from a service provider is desirably 
formulated as an XML document delivered over HTTP to the 
eVault. These XML requests contain two identification sub 
elements. The first element identifies the Service Provider 

15 who is depositing the data or document. The second 
identification sub element identifies the citizen for whose 
eVault the information is destined. The XML request also 
contains a sub element for the digital signature of the 
document by the service provider. In this way the requests 

20 with their digital signatures act as an audit log for non- 
repudiation. 

Securing Requests to eVault 

25 All communication between the eVault and the service 
providers preserves all aspects. of security: authentication, 
integrity, confidentiality and non-repudiation: 

• Authentication: 
30 The service provider from whom the request is sent must 

be identified as the only service provider from whom the 
request could have been sent . Likewise the response from 
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the eVault must be identified as the only source of the 
response . 

• Integrity: 

5 The request and response must not have been altered 

during transmission and it must be possible to prove that 
no such alternation has taken place . 



• Confidentiality: 
10 It must not be possible for an eavesdropper to view the 

contents of the request from the service provider or the 
response to the request from the eVault. 



• Non-Repudiation : 
15 It must not be possible for the service provider to 

disclaim sending the request at some point after it has 
been sent. Likewise it must not be possible for eVault 
to disclaim sending the response. . . 

20 The eVault architecture comprises two principal mechanisms 
to ensure the security of the requests and responses: - 

All XML requests submitted to the eVault are passed over 
secure protocol channels such as HTTPS. HTTPS is the 

25 Hyper Text Transfer Protocol over Secure Sockets Layer 

(SSL) . SSL uses a combination of asymmetric and symmetric 
encryption, which provides integrity, authentication and 
confidentiality. SSL does not allow each request and 
response to be captured in a manner where it can be used 

30 for non-repudiation. However, using SSL improves the 

performance of the system especially with long documents 
or high volumes of requests from the same service 
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provider compared with a mechanism to individually 
encrypt each document . 

Each service provider request and response is digitally 
5 signed in order to support a non-repudiation audit log. 

Web Channel Subsystem (815)_ 

This channel services all Hyper Text Transfer Protocol 
10 (HTTP) requests to the eVault . There are three clients who 
may make requests through this channel; Service Providers, 
citizens and the eVault managers and administrators. This 
system will accept, interpret and formulate responses to 
these HTTP requests. 

15 

• The J2EE architecture defines two separate but related 
components in this subsystem. The first is the web server, 
which manages the low level communications with the clients, 
delivers static web pages and passes dynamic requests from 

20 the clients to and deliver responses from, the second 
component, the Servlet engine. Servlets' are programs, which 
extend the behaviour of the web server. They run within a 
defined environment, the Servlet engine, which provides them 
with a well-defined interface to the web server. Servlets 

25 and their associated programs, Java Server Pages (JSP) , may 
be used to customise the behaviour of the web tier for the 
eVault. 

Telephone Channel Subsystem (820) 

30 
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The channel services all telephony requests to the eVault. 
There is only one client who may make requests through this 
channel, the citizen. This system will accept, interpret 
and formulate responses to these telephone based requests. 
5 The telephone channel will act as an Interactive Voice 
Response (IVR) system but will use voice recognition 
software to translate the voice requests of the citizen to 
electronic requests which can be satisfied by the business 
logic subsystem. The electronic responses from the business 
10 logic subsystem are finally translated to a voice response 
to the citizen. Using voice recognition and authentication 
instead of tone dialling and PIN identification will make 
for a much more positive experience for the citizen. 

15 

eVault Administration Subsystem (810) 

All administration and management of the eVault is typically 
done through the web channel over a web browser. Once the 

20 administrator has authenticated to the eVault, all 
communication is via the Secure Sockets Layer (SSL) 
protocol. As with the citizen access through the web 
channel, administrators will be biometrically authenticated 
before being given access to the system. Administrative 

25 functions will include such processes as enrolment and 
citizen support. 

eVault Business Logic Subsystem (825) 

30 This is the heart of the eVault' s business processing. It 
manages the business processes through which the citizens, 
service providers and administrators interact with the 
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e Vault. All the behaviour related to document management, 
document requests, document signing, eVauit administration 
etc. is performed in this subsystem. All interactions 
between the different enterprise information systems are co- 
5 ordinated by the business processes within this subsystem. 

The telephony and web channels accept the requests from the 
clients, translate these requests to a common electronic 
format and pass them to the business logic subsystem for 

10 processing. The business logic subsystem then co-ordinates 
activity between the different Enterprise Information 
Systems such as the biometric subsystem, the data store and 
the external document stores to satisfy the request. Once 
the request is returned to the channels, it is translated 

15 into the appropriate medium of the channel and requestor 
i.e. voice replay, HTML or XML. 

This design implies that the business logic subsystem is 
independent of the source of the request. When new channels 
20 are added, such as mobile or email, the business logic can 
continue to operate without change. 

Biometric Subsystem (830) 

25 The biometric subsystem is represented as a single logic 
block, which contains all the elements required for the 
biometric processes of enrolment and authentication. 

Enrolment 

30 

This is the most fundamental process in the operation of a 
biometric system and is implemented using an Authentication 
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Engine. Much of the accuracy and performance of subsequent 
biometric requests depend on the enrolment process and 
system. During enrolment, the citizen's identity is 
associated with a number of biometric samples captured from 
5 the citizen. 



The enrolment process may optionally include a uniqueness 
check. This determines if the citizen has already an 
allocated eVault . This prevents the citizen from 

10 inadvertently having two or more eVaults. The uniqueness 
check requires the biometric identifier, created from the 
sample from the citizen, being compared with all other 
biometric identifiers in the system. This is termed a "one 
to many match" and is one of the most time-consuming and 

15 functionally complex processes within the biometric 
subsystem. Enrolment takes place in trusted third party 
centres . 



20 



Authentication 



The citizen presents himself /herself to the Service Provider 
or other enrolment application. During the authentication 
process, the citizen makes a claim as to his / her identity 
and supplies a biometric sample. The matching process will 

25 compare the supplied biometric identifier with the biometric 
identifier captured during enrolment. Multi-modal biometrics 
will allow multiple biometrics i.e. the finger and the voice 
to be used together or as a substitute for one another 
during the authentication process. The use of multi-modal 

30 biometrics will depend on the security and convenience 
requirements of the system. 
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This Biometric Subsystem conceptually forms part of the J2EE 
Enterprise Information System Tier. The actual technology 
used will depend on the choice of biometric modality being 
implemented,. 

5 

Logical & Physical Document and Data Store 

The eVault stores documents and data both physically and 
virtually. Physical storage refers to the actual data and 

10 documents being stored on the disks of the eVault using a 
document repository (835) . This information is under the 
direct control of the eVault. The birth certificate of the 
citizen may be an example of a document held physically 
within the eVault. It is a document produced by a government 

15 body but would be held by the citizen in the eVault and it 
never changes or is updated. 

Virtual storage refers to the actual data and documents 
being stored external to the eVault in one or more external 

20 document stores (840) . This information is not under the 
direct control of the eVault but is accessed through the 
eVault. To the citizen there is little distinction between 
documents stored physically and virtually in the eVault. If 
the citizen attempts to access a document stored virtually, 

25 then the eVault will communicate with the external system 
holding the document and request the document on behalf of 
the citizen. An example of a document being stored in the 
virtual vault might be a passport. The electronic passport 
document will continue to reside in the government system 

30 but the citizen may view it through his / her eVault. 
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External Document Accessors Subsystem (840) 

The previous section explained the concept of the virtual 
document store where the documents are not stored physically 
5 within the eVault. This subsystem and its document accessors 
are the mechanisms by which the virtual store is 
implemented. The accessors of the eVault are the technical 
gateways through which the eVault will request documents and 
data from the external systems. These external systems 

10 behave as external document and data stores for the eVault, 
however communication to these external systems requires 
more complex processing than accessing documents within the 
internal document store. There may be a number of different 
types of external systems to which the eVault will 

15 communicate. Each may require a different accessor. 

Fig. 8 shows just three examples of external document stores 
but it will be appreciated by those skilled in the art that 
these are exemplary of the implementation of the 
20 architecture of the present invention and it is not intended 
to limit the present invention to any such implementation. 

Requests for information from the external document stores 
will have the same requirements for security as requests 
25 from service providers to the eVault itself. The 
communications channels through which the information will 
be exchanged must be secured and each party must identify 
themselves in order for the exchange to take place. 

30 

Referring to Fig. 9 to 11, which describe a possible 
implementation of the authentication engine, channels into 
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it, and the use of policies associated with each service 
instance to define the biometric (or other) confidence 
required for that service. The system provides an 
authentication service utilising multi level authentication 
5 based on multi modal authentication methods. In the example 
of Figure 9 a user may interface with a service provider of 
the system via four access points (900) (Step 1) . The 
request includes a claim of identity, wherein the user 
asserts an identity, and a service request. The service 
10 provider may be the same logical entity as the engine 
itself. A service request security policy database maintains 
the permitted contexts in which authentication will be 
provided, dictates the level of authentication required and 
has the associated methods by which a Claim Of Identity will 
15 be sought and satisfied. On receipt of the service request, 
the service provider forwards the service request and 
context information to an authentication broker (910) (Step 
2) . This service request is then compared against a security 
policy datastore ) 915) to obtain the required authentication 
20 method (Step 4) . Each service request may have its own 
security policy to specify authentication level and method 
depending on the context information provided. . 

In a first embodiment the authentication broker, on receipt 
of the authentication method from the security policy 
datastore, may forward this to the service provider (Step 4) 
which then independently effects communication with an 
authentication service (920) (Step 5a). The Authentication 
Service will process the identity claim in the context of a 
service request and return an approval or denial of 
assertion. In a second embodiment the steps 4 and 5a are 
combined by enabling direct communication between the 



25 



30 
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authentication broker (910) and Authentication Service (920) 
(Step 5b) such that the service provider (905) simply 
receives an authentication or denial of authentication back 
from the authentication broker. Once the user has been 
5 authenticated, he is then free to effect further 
communications with the e Vault . 

Figure 10 shows the components and workflow within a 
biometrically enabled authentication engine and associated 

10 authentication service, which are utilised during 
authentication of a user. The authentication service parses 
and evaluates the initial authentication request within the 
context of a specific function or service request, before 
passing an identity claim and authentication data to an 

15 engine (1000) for verification. Although it is shown in the 
context of two distinct elements, it will be appreciated 
that the engine and service may be integrally formed within 
a single entity. The authentication service processes 
identity claims in the context of a service request and 

20 returns an approved or denied status. The Authentication 
Engine is adapted to service multi modal identity requests 
and interface directly with required underlying secure data, 
be they encrypted text, PKI certificates, biometric 
templates or the like. An engine provides for high volume 

25 transaction processing in an environment managed by the 
authentication service . 

The service requests can therefore range from simple 
information requests to sensitive transactions and the 
30 authentication service will dynamically determine and 
present the request for the associated level of identity 
verification. 
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Two interpretations of this are possible: - 

• Present to me .the available service functions that I can 
choose from according to the channel I am using (e.g. 

5 phone / internet / front desk) and the context (which 

eGovernment service provider or other service provider) 
appropriate to the authentication methods I currently 
have at my disposal on this channel. 

• I present the highest level of Claim Of Identity that I 
10 am able to using this channel and the authentication 

methods available and am presented with the available 
Service Functions I can choose from. 

The Claim Of Identity can be satisfied by the following 
15 mechanisms: - 

• Username & Password / PIN. 

• Client PKI Digital Certificate. 

• Biometric Fingerprint. 

• Biometric Voice Sample. 

20 • Other biometric type or multi-modal biometric samples 

It will be appreciated that the illustrated mechanisms are 
exemplary and other mechanisms can be supported going 
forward and existing mechanisms may be combined to achieve 
25 the highest level of identity verification. 

The Authentication Service will present the service provider 
with the mechanism to capture the Claim Of Identity from the 
citizen. This service needs to be capable of processing very 
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large numbers of simultaneous authentication requests and is 
built along typical validation processing system lines using 
Transaction Processor, Messaging and RDBMS components. 

5 

The authentication service is designed to sit on top of the 
authentication engine. The authentication engine will 
encapsulate the various Claim Of Identity verification 
processes or sub-systems and present them using a uniform 
10 high level application programming interface. This will 
allow maximum scalability of authentication mechanisms and 
provide for the possible inclusion of additional 
authentication mechanisms in the future. 

15 The eVault provides a framework and application architecture 
within which certified information can be securely received, 
stored, accessed and released under tightly controlled 
circumstances from a central repository. As shown in Figure 
11 this information is provided to the user once 

20 authentication has been effected. 

A security policy database (1110) sets and controls the 
rules that the citizen has selected regarding access and 
release of Information Types and maintains the permitted 
25 contexts in which certified information will be provided. 

An information request ( Step 1) is made by the citizen and 
the service provider and received by the eVault Listener 
(1100) which asks the eVault Access Broker (1105) (step 2) 
30 if the information can be made available according to the 
channel and context of the request and the current 
authentication level of the Citizen. 
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Assuming the clearance is given the information request is 
forwarded to the certified information repository retrieval 
agent (1115) (step 3), which sources the information from 
5 within its physical storage or by brokering a request to the 
original' source to provide the Information, on behalf of the 
citizen. The Information is typically provided to the 
Information Presentation agent (1120) in an XML format (Step 
4), which is then parsed for presentation according to the 
10 channel that the citizen is using and the eGovernment 
service providers capabilities. For example the information 
may be parsed for presentation on an automatically completed 
web form or passed to a A text-to-speech' service integrated 
with the IVR system in use. 

15 

Figure 11 illustrates how the security architecture may be 
configured to safeguard the authentication and eVault 
services. This diagram presents the schematic within a 
security zones context. 

20 

The following summarises advantages and features of the 
invention. 

The eVault enables the citizen to manage and securely store 
25 personal information and documents electronically through a 
single virtual database system. Biometric identifiers are 
stored in the eVault. 



30 



Access to the eVault (view/add/update/delete/send/sign) is 
via a secure biometric authentication process for all of the 
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data and some items of data can be accessed via tokens, pins 
& passwords . 



The eVault also provides a secure mailbox storage 
5 functionality. Some of the citizen data is certified. The 
citizen can store and access their private PKI key securely 
from the eVault, and can perform operations within the 
eVault using that key. 

10 Workflow Processing Functionality 

The eVault system provides workflow functionality. The 
eVault workflow system enables the completion of eService 
application forms online typically using the Internet as the 
15 delivery channel and using the eVault data store to provide 
information to the 'form' in an automated process, 
subsequent to a successful biometric authentication request. 

The electronic 'forms' at a service provider outside the 
20 eVault, use. a data definition and data identification 
capability to calculate which items of citizen data that the 
service provider will attempt to extract from the eVault 
data store to complete one or more of the forms. The eVault 
provides the items of data that it can, and also identifies 
25 back to the eService 'form' , which items of data need be 
input manually. 

General Processing Functionality 

30 The eVault provides the ability of linking a citizen 
directly to electronic transactions using biometrics as the 
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biometrics represents the citizen uniquely. The eVauit 
protects the privacy of the citizen, by preventing access to 
the data by all parties other than the citizen, via the use 
of biometric technologies. 

5 

The eVauit performs a biometric authentication prior to 
accessing any data contained in the system (personal 
information, documents, mailbox etc.). The eVauit supplies 
citizen data to external systems based on a positive 
10 biometric authentication by the citizen. Based on user 
defined policies, tailored to specific service providers, 
such data may also be released. 

The eVauit provides the ability for secure communications to 
15 be enabled between the citizen and service providers, by 
allowing the citizen to store a personal PKI key in the 
eVauit and which is easily accessed as required. 

In order to improve the security of managed documents, or 
20 data which are remotely stored from a user, the present 
invention provides for the association of a biometric 
identifier with a key or keys, typically a private and 
public key so as to effect more secure generation and 
association of electronic signatures with documents. 

25 

Although presented in the context of documents stored in a 
user's e Vault, the electronic signatures protected by 
biometrics, may also be used to generate signatures on 
documents used and stored externally to the eVauit. 

30 
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An example of the enrolment process to an eVault of the 
present invention is shown in Figure 12 wherein the 
following steps are identified. These steps are shown for 
illustrative purposes only and it will be appreciated that 
5 the skilled person will not limit the present invention to 
any exact replication of such steps. 

Step 1, the person. being enrolled (An enrolee 300) connects 
over a network (305) to an enrolment application (310) which 

10 as described previously is interf aceable to the eVault 
architecture. The connection to the network (305) typically 
involves the supply of a biometric sample to the system, the 
biometric sample being provided to the system by the enrolee 
(300) utilising a biometric capture device (301) . It will be 

15 understood that the network can be a wide area, local area 
or even a personal area network . 

Step 2, the enrolment application (310) captures enrolment 
data on the individual (for example, name, address, date of 

20 birth etc.). It will be appreciated that this enrolment data 
could be input on the basis of a prompt for specific 
information from the enrolment application and could be 
implemented over a locally installed application or for 
example using a web based server. This enrolment may also 

25 include one or more user identity claims. The amount and 
nature of this information can vary depending on the 
required information for the specific installation of the 
system and it will be understood that such information may 
vary depending on the installation environment where the 

30 system of the present invention is intended for use. On 
capture of the specific identifiers by the enrolment 
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application, the captured samples are then forwarded to a 
biometric authentication engine (315) which may (depending 
on its configuration) carry out a uniqueness check on the 
biometric samples taken at enrolment. The uniqueness check 
will typically be implemented where the system is configured 
to only associate a single biometric identifier with a 
single user identifier whereas in other implementations a 
user may have two or more suitable user identifiers 
associated therewith, each user identifier being associated 
with the same biometric sample. 



Step 3, if a user successfully enrols, their enrolment data 
including the biometric samples are stored in a persistent 
data store (shown as a biometric database (320)) within the 
eVault associated with or defined for that user. 



Step 4, based on data requested at step 2, an administrator 
decision or a configuration parameter, the enrolee (300) 
will be designated as one entitled to create electronic 
20 signatures. 



Once designated, in Step 5, this results in a request being 
sent to an electronic signature application (325) to cause 
it to generate the necessary public and private keys. It 
will be appreciated that using a system according to the 
present invention that a biometric identifier is used to 
identify a user of the system and to cause it to generate a 
key or keys for that user or to associate that user with a 
key or keys. Once these keys have been generated and 
associated with a biometric identifier they can then be 
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accesseci by presentation of the biometric identifier without 
any subsequent enrolment or alternative traditional access 
methodology. 

5 The e-signature application requests a public-private key 
pair to be generated by a Key Trust (330) . The Key Trust 
typically uses a HSM (Hardware Security Module) to generate 
this key. The HSM is a tamper-resistant device that contains 
cryptographic capabilities, and it will be appreciated that 
10 alternatives (such as a software implementation) that offer 
suitable equivalent capabilities may be equally applicable. 

The request to the HSM is typically signed by the component 
generating the request (the e-signature Application (325) ) . 

15 This signature may optionally include in the signing data 
the signature generated by the Authentication Engine (315) 
in step 4 when making the request of the e-signature 
application. The invention allows for and recognises a 
situation where all parties in the communication from the 

20 user to the key trust can sign (and optionally encrypt) 
messages. Each of these signatures can then be checked by 
the key trust before allowing the signature key or keys 
associated with the user to sign a document. 

25 The HSM generates the keys and optionally exports the public 
key. In accordance with known principles, the private key is 
stored in a key store database within the key trust (330) . 
Each private key stored in the database is encrypted or 
wrapped under a separate cryptographic key known only to 

30 (and stored on board) the HSM. Strong cryptographic 
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techniques (e.g. AES, 3DES) should be used to encrypt the 
private keys. 

Step 6, the HSM component of the Key Trust (330) exports the 
5 public key component to the e-signature Application (325) 

Step 7, the received public key component is then forwarded 
together with the necessary registration/enrolment details 
to a Certificate Authority (340) for signing. It will be 
10 appreciated that a variety of methods can be used to export 
the key, including both off-line and on-line. A variety of 
protocols can also be used - for example, Public Key 
Cryptographic Standard number 10 (PKCS#10) . 

15 The Certificate Authority (340) then signs the public key 
using its private key. The resulting certificate can then be 
stored in a directory service — for example, an LDAP 
(Lightweight Directory Access Protocol) (345) compliant 
directory (step 8a) . 

20 

Step 8b, a success (or failure) status dependant on the 
generation of the certificate is returned to the E-signature 
application (325) . This status can be returned in an on-line 
or off-line mode depending on the CA configuration. In the 
25 case of a success status' code, the digital certificate can 
also be returned if required. The certificate may be in 
X.509 format, amongst others. 



3DOCID: <WO_021 03496 A2_l_> 



WO 02/103496 



PCT/IE02/00081 



-46- 

In step 9, the E-signature application returns a success or 
failure code to the authentication engine (315) . This status 
code, again, can be returned using an on-line or ' of f-line 
protocol. Upon receipt of a successful status code, the 
5 authentication engine (315) registers that enrolee as 
enrolled for the E-signature application. The enrolment 
application and enrolee may optionally also be notified of 
the success/failure of the operation (through steps 10 and 
11) • 

10 

It will be appreciated that steps 7 through 8b are carried 
out where an external certificate authority is being used. 
The invention is also designed to work in a situation where 
the key-pair authenticity is self asserted or asserted by 
15 the key trust. In this case, the steps outlined above for 
interacting with an external CA are not required. 

It will be appreciated that although above components of the 
system have been described with reference to discrete 

20 modules such as a Authentication Engine (315) etc., that 
this has been done for ease of explanation and that two or 
more applications could be implemented on the same hardware 
or software platforms. It will be further understood that 
the communication between the individual components could be 

25 effected over a local or wide area network. 

Message Integrity 

It will be appreciated that as the above described steps 
relate to the formation of a specific security identifier 
30 associated with a specific user that it is typical that 



ISDOCID: <WO_02103496A2_I_> 



WO 02/103496 



PCT/IE02/00081 



-47- 

secure communication protocols should be utilised such that 
all messages in the scheme (in particular messages 
identified in Steps 2, 4, 5, 6, 7, 8b, 9) have integrity 
guarantees in place. This could typically include a signing 
5 ar.d/cr an encryption of these messages by the originating 
parties, but it will be appreciated that alternative 
methodologies could be envisaged which require only some or 
none of techniques to be utilised. 

10 En rolment with Enroler Signature 

It will be appreciated that the above flow steps outline a 
process for the generation of a digital certificate for 'a 
specific user that does not require any specific enroler 

15 signature. The present invention may provide ' in an 
alternative embodiment a variant to the process hereinbefore 
described wherein the enrolment data request is also 
biometrically signed by an enroler. This, process is very 
similar to the simpler enrolment outlined above and can be 

20 seen in the Figure 13. The same reference numerals will be 
used for similar components or process flow steps. In the 
eVault architecture the enroler will biometrically 
authenticate through their eVault when enrolling the new 
user. The enroler is a citizen, who already has a personal 

25 eVault associated with them and who has privileges allowing 
them to enrol other users. Part of the data stored during 
enrolment in a user's eVault will indicate who the enroler 
for that new citizen or user was. During the new enrolment, 
the enroler is authenticated against their own personal 

30 biometric identifier within the eVault to ascertain and 
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confirm their correct identity prior to any access being 
obtained. 

In this modification to the process flow outlined above, 
5 Steps 1 and 2 (the connection and submission of enrolment 
data) are broken into 2 parts (la,b and 2a, b). Steps la and 
2a are the same as in the configuration shown in Figure 12. 
Step lb involves an enroler (401) connecting to the 
enrolment application, which is typically on the same 

10 interface and network connection. The enroler is also 
usually in the same physical location as the enrolee, 
although it will be appreciated that alternatives techniques 
such as using voice recognition may allow the enroler to be 
in a remote location to the enrolee, yet still be able to 

15 enrol the enrolee with the system. Step 2b involves the 
enroler (401) supplying a biometric sample and signing the 
enrolment request of the enrolee (300) . This signature will 
then be included in the message payload to both the 
authentication engine and the e-signature application. It 

20 will be appreciated that this signature may be selected from 
one of a number of different signature types including those 
generated using a key of the enroler, a key of the server 
application or a key which is associated with a biometric 
identifier of the enroler. 

25 

One or both of these systems may then use a privilege 
management database to ensure that the enroler was entitled 
to enrol the enrolee, although it will be appreciated that 
it is not intended to limit the present invention to such 
30 hierarchical management systems. 
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It will be appreciated that in the enrolment process 
outlined in Figures 12 and 13 that typically a separate 
enrolment checking procedure is implemented in either the e- 
5 signature application (325) or the Authentication engine 
(315) to verify the accuracy of the enrolment prior to the 
generation and signing of the keys (steps 5 onwards) . This 
is not shown in the diagram for simplicity, but will be 
appreciated by the skilled person as forming part of the 
10 invention. 

Once an enrolee (300) has successfully enrolled in the 
eVault system of the present invention, he now adopts the 
persona of a client to the system and is now free to 

15 generate biometrically protected signatures for application 
to specific documents, and may be able to act as an enroler 
for additional persons or users (if so authorised) . A 
typical generation process is shown in Figure 14, and will 
be described with reference to a document repository (DR) as 

20 a partner application, although it will be appreciated that 
such an example is not intended to limit the present 
invention to interface only with document repositories. 
Again, the same reference numerals will be used to describe 
similar components to the system. 

25 

The following steps are followed to sign a document: 

A client (300) connects to a document management engine or 
document repository ( 505) and provides an identity claim and 
30 a biometric sample (Step 1) . The biometric sample is 
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encrypted under a key known to the Authentication Engine 
(AE) (315) (e.g. the AE' s public key). This ensures that the 
partner applications such as document repositories (DR) do 
not gain access to the biometric information. 

5 Client -> DR: claim, Eae (biometric sample) 

Optionally, to increase user privacy, the claim may be 
specific to the DR, and the mapping between the DR-specific 
claim and the user's AE claim may be encrypted along with 

10 the biometric sample, and only visible to the AE. This would 
prevent DRs colluding to compare claims. In addition, by 
including the claim (DR-specific or otherwise) encrypted 
with the biometric sample, a dishonest DR is prevented from 
attempting to find other claims, through repeated requests 

15 to the AE, that falsely match the submitted biometric 
sample . 

The document repository (505) forwards the claim of identity 
and the biometric sample to the Authentication Engine (315) 
20 (Step 2). The message also includes an application 
identifier (id) . This message may be signed by the document 
repository, which as shown in Figure 3 is accessible or 
resident within the eVault architecture also. 

DR -> AE: claim, E AE (biometric sample), application id 

25 

The Authentication Engine (315) verifies the identity of the 
user, using a biometric matching algorithm, and returns an 
authentication ticket to the partner application (document 
repository) (505) (Step 3). This is the user's claim of 
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identity signed by the authentication engine. It typically 
includes a time stamp, expiry date and application id. This 
authentication ticket can be passed by the DR (505) to the 
client to streamline the authentication process to other 
5 applications and the AE later. 

auth_ticket := Sae (claim, application id, timestamp, expiry 
date) 

AE -> DR: auth_ticket 

10 The Document Repository (505) determines (based on the 
authentication success/failure) and its privilege management 
engine that the user is entitled to see the document and if 
this is the case, returns the document to the client (300") 
along with the authentication ticket (Step 4). 

15 DR -> Client: document, auth_ticket 

It will be understood that the method of the present 
invention may utilise one of a number of methods for 
returning the authentication ticket to the client including 
20 but not limited to the use of cookies. 

The auth ticket is ultimately used by the key trust KT (330) 
and may be optionally encrypted with the KT's public key to 
increase privacy of communications. 

25 

An identifier of the e-signature application may optionally 
be included in the ticket to prevent it being used by 
another entity. 
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The user may modify the document contents. The client 
calculates the digest (hash) for the document to be signed 
and encrypts under the public key of the KeyTrust (KT) (330) 
5 (Step 5) . 

enc_digest := E PuKT (digest ) 

it will be appreciated that an alternative implementation of 
this scheme could be built where symmetric key cryptography 
10 is used in some or all messages. 

In Step 6 the Client forwards authentication ticket, 
encrypted digest to the e-signature Application (325) (AE) 

client -> AE: auth_ticket, enc_digest 

15 

The e-signature Application (325) verifies the 
authentication ticket, previously issued by the 
authentication engine (315) in step 3. It may optionally go 
on-line to the authentication engine to do this (steps 7,8). 

20 Depending on its policy configuration, it may trust the 
authentication ticket at this point (it is signed by the AE) 
or it may request a re-authentication if a) it is configured 
to do so at each signing or b) the authentication ticket is 
no longer valid (for example, if the expiry period has 

25 elapsed) . 

It should be noted that should the ticket not be present or 
a re-authentication required, a formal authentication 
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(biometric, claim) may be carried out by the e-signature 
application (325) using the authentication engine (AE) (315) . 

Once the signer has been authenticated, the e-signature 
5 application (325) signs the authentication ticket and 
encrypted message digest. This is then forwarded to 'the Key 
Trust (330) (Step 9) 

KT_ticket := S eS ignApp (auth_ticket , enc_digest) 
eSignApp -> KT : KT_ticket 

10 

The Key Trust (330) verifies the signature on the KT_ticket 
so as to ensure it came from a trusted e-signature 
application. It can then verify the authenticity of the 
authentication ticket (signed by the AE) , decrypt the 
15 encjdigest to get the document digest for signing. 

It will be appreciated by the skilled person that in most 
secure operations, all encryption and decryption operations 
will be carried out by the Key Trust HSM. 

20 

It then retrieves the private key from its database and 
decrypts it using the key corresponding to the claim signed 
by the AE (Step 10) . This key could be symmetric or 
asymmetric and in the case of a symmetric key could be a 
25 single key used across all claims or a derived key - the 
derivation based on, for example, the claim of identity. 
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It will be appreciated by the skilled person that the 
provision of multiple signatures by the various trusted 
components within the process steps of the present invention 
adds to improvements in the overall security robustness of 
5 the system. 

The KT (330) then signs the digest , possibly adding a 
timestamp if necessary. It will be appreciated that these 
timestamps may be server assigned timestamps and/or client 
10 assigned timestamps. 

The Key Trust (330) then sends the resulting signature back 
to the e-signature application (Step 11) • 

15 The e-signature application (325) returns the electronic 
signature to the client (300) (Step 12) . 

It will be appreciated that the return of the electronic 
signature may include such optional steps as the validation 
20 of the signature using its own public key from a directory 
(e.g. LDAP (345) ) (Step 13) prior to execution of step 14, 
which is the storage of the electronic signature in the 
document repository (505) . 

25 It will be appreciated that the process flow outlined above 
may be differentiated for situations or circumstances 
wherein the document repository (505) is not fully 
integrated ' with the Authentication Engine (315) . Such a 
modification is outlined in Figure 15. Again, as was 
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utilised previously similar reference numerals will be used 
for equivalent components to the system. In this scenario, 
the flows are very similar, however the document repository 
has no direct link or association with the authentication 
5 engine. This scenario may exist in situations such as: 

1-A customer or client has deployed the e- 
signature product with a document repository 
which has not yet been associated with the 
storage biometric identifiers or; 

10 2. The e-signature signing service is a service 

offered over for example the internet, with no 
integration with local repositories. 



15 



20 



25 



In this case, the Document Repository has its own 
authentication mechanism (e.g. user name and password) for 
authenticating the user. This is shown in step 2. The 
document is returned to the client in step 3 and the digest 
(as in the previous scenario) is calculated in step 4. Step 
5 is similar to that outline in Step 6 of Figure 12 wherein 
the Client forwards the authentication ticket and encrypted 
digest to the e-signature Application (325) (AE) 

Steps 6 and 7 show the e-signature application determining 
that it does not have a valid authentication ticket. This 
may occur in situations where the biometric identifier has 
not yet been presented to the system or the ticket has 
expired. It then requests a biometric and claim and forwards 
these to the AE for authentication (steps 6,7,8,9). 
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The operation of the AE including the data in the 
authentication ticket is as outlined previously. 

It will be appreciated that in case of user identification/ 
5 the claim is not present in data flows 7 or 8 - but is 
determined by the AE and returned in data flow 9. 

Steps 10 through 15 correspond with steps 9 through 14 in 
the previous (integrated document repository) scenario 
10 outlined in Figure 14. 

To verify an asymmetric signature, a verifier usually 
obtains the signer's digital certificate, and uses this to 
verify the signature. Where a Certificate Authority is not 

15 used, other methods to verify the signature can be applied. 
The verifier may request, through an optional arbitrator 
application, that the KT send the key material necessary to 
verify the signature directly to the verifier. In the case 
of asymmetric signatures this will be the public key 

20 corresponding to the private key that signed the document. 
Using traditional cryptographic techniques and protocols, 
the KT may securely send the key to the verifier, and prove 
that this key originated from the KT . 

25 However, for cases where the KT does not wish to send key 

material to the verifier, the protocol illustrated in Figure 
16 may be followed to verify the signature. Such cases may 
include where a symmetric key signature is used, where the 
KT does not want to release either symmetric or asymmetric 
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key material, or where the verifier cannot perform signature 
verification. 

If a verifier (707) does not already have the document 
5 and/or the signature, then it may obtain these from a 
document repository (steps 1 and 2) . The verifier then 
generates a hash of the document, and sends this along with 
the signature to the e-signature verification application 
(step 3) . Both the signature and hash may be encrypted with 

10 the public-key of the KT, who will perform the actual 
verification, in order to prevent other entities accessing 
it. The verifier may be required to authenticate themselves 
or the request, biometrically or otherwise, to the signature 
verification application and/or the KT . In the case of 

15 biometric authentication, the authentication engine verifies 
the verifier's biometric, returning the result to the 
verification application (optional steps 4-7) 

If the verification application is prepared to verify the 
20 signature for the requesting verifier, then the signature 
and corresponding hash are forwarded onto the KT (step 8) . 
The KT infers from the signature, the identifier of the key 
or keys necessary to verify the signature. The key of keys 
are then retrieved from a HSM or other secure storage (step 
25 9) . The signature is verified using the appropriate keys, 
and an indication of whether a valid signature was present 
is returned to the verification application (step 10) . This 
outcome is then forwarded on to the requesting verifier 
(step 11) . All messages may be encrypted and signed for 
30 security. 
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It will be appreciated that the implementation of the method 
of the present invention has involved authentication of a 
user at the authentication engine, based on a claim and 
their biometric identifier. The authentication engine uses 
5 the claim to retrieve one or more enrolled biometric 
identifiers for the user, against which the submitted 
biometric is compared (a process referred to as 
verification) . However, it will be appreciated that a user 
may be identified by submitting a biometric identifier 

10 alone, without a specific claim. In this case the 

authentication engine will compare the submitted biometric 
identifier against a multiplicity of enrolled biometric 
identifiers (a process referred to as identification) . When 
the AE finds the enrolled biometric identifier that best 

15 matches the submitted one, it will return the corresponding 
identity claim. An application receiving this verified 
claim, can then be assured that this user has been 
authenticated. It will be appreciated that such a method of 
identification without a claim, may be used within the 

20 method and system of the present invention in situations 
where verification has been described. 

It will be appreciated that although the present invention 
has been described with reference to the application of a 
25 digital or electronic signature to documents that the word 
"document'' is intended to cover any electronic object such 
as but not limited to text, pdf, source code, object code, 
binaries, images, multimedia files, transaction data, e- 
mail, messages etc. ) . 

30 
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Once a document has been signed it may later be verified 
using conventional techniques such as that shown, in Figure 
2, and it will be appreciated that no specific biometric 
technologies are. required to verify a signature (for example 
if a CA has been used to certify the public keys). However, 
the KT (and perhaps the e-signature application) can be 
configured to store the signed digests generated for audit 
trail purposes . 



10 It will also be appreciated that if the biometric identifier 
is incorporated into the electronic signature, as was 
described above according to an aspect of the present 
invention, that a modification to this conventional 
technique will be required to decipher the biometric 

15 identifier from the document signature and confirm that it 
is an authentic identifier. 

It will be appreciated that although an exemplary embodiment 
of the present invention has been described for illustrative 
20 purposes as using public key digital signatures, that this 
is not intended to limit the present invention to such 
embodiments and varying implementations such as those using 
a symmetric key algorithm may be found suitable for specific 
applications. The present invention provides for a network 
accessible vault or data repository (eVault) , which may be 
personalised for access by a plurality of users, each user 
having access defined by the user characteristics. By 
including a cryptographic key within the networked storage 
area and limiting access to that key to users having . 
asserted and matched a biometric, the system provides for a 



25 



30 
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network accessible cryptographic key associated with a 
user's biometric. 

The words "comprises/comprising" and the words 
5 "having/including"' when used herein with reference to the 

present invention are used to specify the presence of stated 
features, integers, steps or components but does not 
preclude the presence or addition, of one or more other 
features, integers, steps, components or groups thereof. 

10 

It will be appreciated that in all steps security techniques 
are typically applied to protect the integrity of the 
communications channels and to guarantee freshness of the 
messages. It will be further appreciated that the invention 
15 is not limited to the embodiments described but may be 
varied in construction and detail. 
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Claims 

1. An electronic data vault system (eVault) comprising 
means for securely storing personal data for one or 

5 more users, at least one item of the personal data 

being at least one cryptographic key for the one or 
more users, and an interface for allowing controlled 
access to the system by a user, and wherein the system 
comprises means for performing authentication of users 
10 using biometric matching! 

2. A system as claimed in claim 1, wherein the system is 
adapted to store documents associated with one or more 
users. 



15 



20 



A system as claimed in claim 1 or 2 and additionally 
comprising a data processing system. 

A system as claimed in claim 3 further comprising a 
service provider interface for allowing controlled 
access by service providers for (a) updating the data 
and documents and (b) performing processes requiring 
access to the data and documents. 



25 5 - A system as claimed in claim 4 further comprising a 
policy management system allowing a user to define 
policies controlling the access of specific service 
providers to specific parts of the user data store, 
defining the data that may be deposited by specific 
service providers into a user's datastore, and defining 
default data access levels for service providers not 
specifically identified. 



30 
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6. A system as claimed in any preceding claim, wherein the 
system comprises means for certifying data or 
documents. 

7. A system as claimed in claim 6 where the certification 
process includes one or more of the following steps: 

a) ensuring that the submitted data meets a correct 
predefined format, 

b) the information included in the data or documents 
corresponds to already certified data held in the 
user datastore, 

c) the submitter has the correct permissions and has 
been authenticated to the necessary security level 
for performing the submission of the submitted 
data, 

d) the user has provided permission for the data to 
be submitted, optionally from an identified 
service provider, 

e) the. addition of a timestamp to the submitted 
data, and/or 

f) the application of one or more electronic 
signatures to the submitted data or document, 

8. A system as claimed in any preceding claim, wherein the 
system comprises means for storing the data and 
documents in distributed locations and for presenting a 
single centralised view to users. 

9. A system as defined in claim 8 where the 'distributed 
locations include datastores managed and maintained by 
independent third-party service providers. 
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10. A system as claimed in any preceding claim, wherein the 
citizen interface comprises means for . allowing access 
using a plurality of different types of devices 

5 including telephones, kiosks, ATMs, PDAs, mobile 

devices and Web browsers. 

11. A system as claimed in any preceding claim, wherein the 
system comprises means for performing multi-modal 

0 biometric verification. 

12. A system as claimed in claim 9, further including means 
for executing one or more processes in communication 
with service providers, at least one of the processes 

5 being an enabling of completion of service application 

forms online and for automatically populating parts of 
the forms using data retrieved from within the system. 



13. A system as claimed in any preceding claim further 
comprising means for making at least one cryptographic 
key available for secure communication between the user 
and service providers. 

14. A system as claimed in any preceding claim furthfer 
including means to enable third parties access . to 
documents or data specifically related to one or more 
users, such that the third party may directly request 
the data from the eVault, or the eVault may 
automatically push the data to specific third parties, 
when it is updated within the eVault. 
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15. A method of associating at least one cryptographic key 
with a specific user comprising the steps of: 

a) storing a set having one or more personal 
5 identifiers associated with the user, 

b) linking the set of personal identifiers with at 
least one cryptographic key generated for that 
user, and 

wherein the set of personal identifiers associated with 
10 the user includes at least one biometric identifier, 

and at least one cryptographic key may subsequently be 
accessed by providing at least one biometric 
identifier. 



15 16. The method as claimed in claim 15 wherein at least one 
cryptographic key comprises a set of cryptographic 
keys . 

17. The method as claimed in claim 16 wherein- the set of 
20 keys includes a pair of public and private keys. 

18. The method as claimed in 15 or 16 above wherein the set 
of cryptographic keys includes a symmetric key. 

25 19. The method as claimed in claim 15 wherein at least one 
cryptographic key includes an asymmetric key. 
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20. The method as claimed in any of claims 15 to 19 wherein 
the step of storing a set of personal identifiers with 
the user includes the steps of: 

a) electronically registering the user, 

b) capturing a set. of identifiers presented by the 
user, and 

c) storing the set of identifiers in a datastore. 



21. The method as claimed in claim 20 comprising the 
10 additional steps of: 

a) comparing the captured set of identifiers with 
previously stored identifiers in said datastore, 
and 

b) accepting the captured set of identifiers where 
15 the step of comparing the captured set of 

identifiers does not find a matching previously 
stored identifier. 



22. The method as claimed in any of claims 15 to 21 further 
20 comprising the steps of: 

a) associating the specific user with a pre-existing 
user, 

b) authenticating the identity of the pre-existing 
user, and 

25 c ) storing the set of identifiers for the specific 

user after authentication of the pre-existing 
user. 
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23. The method according to any of claims 15 to 22 further 
comprising the step of requesting a cryptographic key 
or keys for a specific user be generated after the 
biometric identifiers have been associated with and 
stored for that user. 



24. The method as claimed in claim 23 wherein the request 
for a cryptographic key or keys to be generated is a 
signed request. 

10 

25. A method of returning at least one cryptographic key 
for a user, the user having been associated with the 
cryptographic key in accordance with any one of claims 
15 to 24, the method comprising the steps of: 

15 a) receiving a biometric identifier from the user, 

b) comparing the biometric identifier with a 
datastore of previously stored identifiers, and 

c) on matching an identifier in the datastore with 
the supplied biometric identifier, returning at 

20 least one cryptographic key previously associated 

with the stored identifier to the user. 



26. A method of providing a user with access to an 
electronically stored document, the method comprising 
25 the steps of: 

a) receiving a request from a user for a specific 
document, the request including at least one 
biometric identifier for that user, 
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b) comparing the supplied biometric identifier with a 
set of pre-stored identifiers so as to 
authenticate the user, 

c) wherein access is provided to the electronic 
5 document by forwarding a copy of the requested 

document to the user if the step of comparing the 
supplied biometric identifier authenticates the 
user, and 

wherein the biometric identifier is received at a document 
10 repository, the biometric identifier being encrypted prior 
to receipt at the repository, and wherein the repository 
forwards the encrypted identifier to an authentication 
engine where it is decrypted and compared with the set of 
pre-stored identifiers so as to authenticate the user. 



15 
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27. The method as claimed in any of the claims 15 to 26 
wherein at least one cryptographic key is stored in 
the user's personal eVault, or in a logical key trust 
component of that eVault . 



28. The method as claimed in claim 26 wherein the 
authentication engine, on authentication of the 
identity of the user, returns an authentication ticket 
to the document, repository, the authentication ticket 
25 indicating whether the user is authenticated or not. 



29. The method as claimed in claim 28 wherein on 
authentication of the user and receipt of said ticket 
at the document repository, the repository confirms 
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that the authenticated user is entitled to retrieve the 
requested document and, on confirmation of same, 
returns the requested document and authentication 
ticket to the user. 

5 

30. The method as claimed in claim 28 or claim 29 wherein 
the authentication ticket is returned to the user by 
means of a cookie, or other similar means involving 
software tokens, forwarded by the repository to the 
10 user. 



31. A method of applying an electronic signature to a 
document, the method comprising the steps of: 

a) receiving an encrypted digest of a document and an 
15 authentication ticket of a user from said user, 

the document and authentication ticket having 
being forwarded to the user according to the 
method steps of any one of claims 26 to 30, 

b) applying an electronic signature to the verified 
20 authentication ticket and encrypted digest, and 

forwarding said signed combination to a key trust, 
the key trust being adapted to verify the 
authenticity of the applied signature and the 
authentication ticket, 

25 c) on verification of said applied signature and 

authentication ticket obtaining a cryptographic 

key from a datastore associated with the* key 

« 

trust, the cryptographic key selected 4 , being 
associated with the biometric identifier detailed 
30 in the authentication ticket, and 
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d) signing the digest using the cryptographic key, 
the signed digest forming an electronic signature 
for the document linkable to the user. 



32. The method as claimed in claim 31 comprising the 
additional step of verifying the authentication ticket 
received from the user prior to forwarding the ticket 
to the key trust. 



10 33. The method as claimed in claim 31 or 32 comprising the 
further steps of: 

a) receiving the electronic signature from the key 
trust and returning the electronic signature to 
the user, and 

15 b) storing the electronic signature. 



34. The method as claimed in any one of claims 31 to 33 
wherein the key trust decrypts the cryptographic key, 
the decryption being effected using a key corresponding 
20 to the claim identity signed by the authentication 

engine. 



35. The method as claimed any one of claims 31 to 33 
wherein the key trust decrypts the cryptographic key, 
25 the decryption being effected using a key corresponding 

to one or more claims . 
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36. The method as claimed in claim 34 or 35 wherein the key 
used to decrypt the selected cryptographic key is a 
symmetric key. 

5 37. The method as claimed in claim 34 or 35 wherein the key 
used to decrypt the selected cryptographic key is an 
asymmetric key. 

38. The method as claimed in any one of claims 15 to 37 
10 wherein the biometric identifier is selected from one 

or more of the following biometric types: 



15 



20 



a) 


iris, 


b) 


voice, 


c) 


finger, 


d) 


blood, 


e) 


DNA, 


f) 


Retina, 


g) 


Face, 


h) 


Hand geometry. 



39. The method as claimed in any one of claims 31 to 38 
wherein a signing of a document includes the 
application of a time stamp to that signature. 



25 40. A system adapted to provide for the encryption of one 
or more electronic documents-, said system having: 
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a) a first datastore adapted to store a plurality of 
identifiers associated with one or more users, 

b) means for associating an electronic document with 
a specified user, 

5 c) means for encrypting the associated document with 

an encryption based on the one or more identifiers 
associated with that user and 
d) wherein the one or more identifiers include at 
least one biometric identifier linkable to that 
10 user. 

41. A system adapted to provide for the signing of one or 
more electronic documents, said system having: 

a) a datastore adapted to store a plurality of 

15 identifiers associated with one or more users, 

b) means for associating an electronic document with 
a specified user, 

c) means for signing the associated document with an 
electronic signature based on the one or more 

20 identifiers associated with that user and 

d) wherein the one or more identifiers include at 
least one biometric identifier linkable to that 
user. 

25 42. A security system adapted for use with at least one 
associated key trust, the system comprising: 
a) a datastore adapted to store a plurality of sets 

of personal identifiers, each set having one or 

more biometric identifiers, 

30 b) means for associating at least one cryptographic 

key from the key trust with a specific user, 
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c) means for accepting the associated at least one 
cryptographic key from the key trust, 

d) means for linking the set of personal identifiers 
with the requested at least one cryptographic key. 

43. The system as claimed in claim 42 wherein the means for 
associating at least one cryptographic key comprises 
the steps of requesting the generation of at least one 
cryptographic key from the key trust. 

44. The system as claimed in claim 42 wherein the means for 
associating at least one cryptographic key comprises 
the steps of providing the key trust with at least one 
cryptographic key . 



45. The system as claimed in any one of claims 42 to 44 
wherein the at least one cryptographic key is at least 
one pair of keys. 



20 46. The system as claimed in claim 45 wherein one key from 
the at least one pair of keys is requested from the key 
trust for the purpose of effecting encryption and/or 
securing communication-. 

25 47. The system as claimed in claim 42 wherein at least one 
cryptographic key is a cryptographic key previously 
associated with the specific user. 



15 
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48. The system as claimed in any one of claims 42 to 47 
further including means for electronically signing the 
request for requesting at least one cryptographic key 
from the key trust. 

49. A security access system for providing a user with 
access to an electronically stored document, the system 
comprising: 

a) means for receiving a request from a user for a 
specific document, the request including at least 
one biometric identifier for that user, 

b) means for comparing the supplied biometric 
identifier with a set of pre-stored identifiers so 
as to authenticate the user, and 

c) means for forwarding a copy of the requested 
document to the user if the means for comparing 
the supplied biometric identifier authenticates 
the user. 

50. The system as claimed in claim 4 9 wherein the biometric 
identifier is received at a document repository, the 
biometric identifier being encrypted prior to receipt 
at the repository, and wherein the repository forwards 
the encrypted identifier to an authentication engine 
where it is decrypted and compared with the set of pre- 
stored identifiers so as to authenticate the user. 

51. The system as claimed in claim 50 wherein the 
authentication engine, on ■ authentication of the 
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identity of the user, is adapted to return an 
authentication ticket to the document repository, the 
authentication ticket indicating whether the user is 
authenticated or not. 

5 

52. The system as claimed in claim 51 wherein on 
authentication of the user and receipt of said ticket 
at the document repository, the repository is adapted 
to confirm that the authenticated user is entitled to 
10 retrieve the requested document and, on confirmation of 

same, is adapted to return the requested document and 
authentication ticket to the user. 



3DOCID: <WO_02103496A2_L> 



WO 02/103496 



PCT/IE02/00081 





Step 4 



Document 



Document Signature 



c 
o 




Figure 1 



_02103496A2J_> 



WO 02/103496 



2/15 



PCT/IE02/00081 



Document 



Document Signature 



Step 20 



Compute 
document hash 




Step 21 



Hash 



Hash 



Step 24 




NO 






Invalid Signature 





Step 22 



Step 23 



Figure 2 



3DOCID: <WO_02103496A2_I_> 



WO 02/103496 



3/15 



PCT/IE02/00081 




SDOCID: <WO_02103496A2J_> 



WO 02/103496 PCT/IE02/00081 

4/15 






10 



i 

> 
0 

£ 

CO 

r 

T5 
O 



C/) 
CO 
Q> 

o 

2 

<D 
> 

(U 

Q 

0) 

o 

"E 

CO 
"*-» 

3 



o 
■> 

i- 

CO 
o 

CO 



CO 
0) 

Q. 

a. 

CO 

c 

CO 

CO 
CD 



c 
a> 

c 
o 

N 



mm 
f 



3 8 



fir 

I-! 



T3 g" 

•:.0;^o-' 



2 to 




... COl 

; -cy -co v s 



- © in 
o z 



r 0)r 

T3>co - 

-O' -co* 
ss-/.a>, , 
p 
o 



- to 

'C-o •••• 



<D 

a 



c/) 



O) 

c 

"53 
co 
o 
o 
o 



o 

E 
c 

a> 
> 
o 
O 



1SDOCID: <WO_02103496A2_I_> 



WO 02/103496 PCT/IE02/00081 

5/15 




*> § 

£ o £ 

o .52 o 

a m y- 




T— < 



i 

E 

CO 

I 

"5 
■o 
o 



co 
a> 
o 
o 

La 

> 

Q 

O 

OX 
CO 

5 



CD 

o 



a> 
CO 



"a. 

cu 

•a 
c 

(0 
(0 

a> 



c 

CD 

c 

CD 
N 



:E :- ; Jr L 



- TO - 



-o 



q o 




. . a> » 



£ o 

; .o;-z 



• Q CL 



is" ■ 1 

. Q.:;<1) 1 

lis < 



CD 
O 



CD 
CO 

CD 
*#— 

o 
en 
c 

"co 

CO 
CD 
O 
O 



c 

CD 

E 
c 
i— 

CD 
> 
O 

a 



> >, 

O i- 

«« g- 
c — 

CD *Z 

N £ 
CD 

•ts > 

O UJ 



in 

9> 



3DOCID: <WO__02103496A2_I_> 



WO 02/103496 PCT/IE02/00081 

6/15 




3DOCID: <WO„02103496A2J_> 



WO 02/103496 



7/15 



PCT/IE02/00081 



eVault System 



Logical Databases Components 
(D 



pre 
Biometric 
Data 



^ Core _ 
General 
Data 

Internal 



(2) 



Extended 
Data 



(3) 

Internal or External 



Logical Database Component Notes: 
(1) Stores Finger and Voice biometric 
templates, (2) Stores general data 
such as name, address, PKI key, 
mailbox data etc. (1 ) & (2) are internal 
to the eVault (3) Stores digital 
documents, eg Passport, Driving 
Licence. Multiple databases can 
exist and can be internal or external 
to the eVault system, ie the Virtual 
eVault concept. 



Figure 7 




)__02103496A2_I_> 




SDOCID: <WO_02103496A2J_> 



WO 02/103496 



9/15 



PCT/IE02/00081 




;SDOCfD: <WO_02103496A2J_> 



WO 02/103496 



10/15 



PCT/1E02/00081 



LO 




Li. 



SDOCfD- <WO_02103496A2_!_> 



WO 02/103496 



11/15 



PCT/IE02/00081 




SDOCID: <WO_02103496A2_I_> 



WO 02/103496 



12/15 



PCT/IE02/00081 




3DOCID: <WO_02103496A2J_> 




3DOCID: <WO_02 103496 A 2_l_> 



WO 02/103496 



15/15 



PCT/IE02/U0081 




• 3DOC1D: <WO_02t03496A2J_> 



